1. Technical Field
This disclosure relates to a tool for extending a modeling environment using legacy event based applications. In particular, this disclosure relates to a tool that allows modelers to create modeling elements for a modeling environment toolbox from Graphical User Interface (GUI) APplications (GAPs), and generate source code to control and manipulate GUI objects of the GAPs represented by the modeling elements.
2. Background Information
Integrated systems are composed of components that exchange information, also referred to as interoperating components. Components of integrated systems may include different legacy event-based applications such as Graphical User Interface (GUI) APplications (GAPs). Organizations use legacy GAPs to assist business operations to automate business processes, for example, increasing the speed and effectiveness of information exchange.
Organizations find reengineering GAPs into programming components difficult because of brittle legacy architectures, poor documentation, significant programming effort, and subsequently, the large cost of these projects. Because businesses use successful GAPs for decades, managers are reluctant to authorize changes to source code that may break GAPs and disrupt well-established business services. Many organizations explore how to include legacy GAPs in new integrated systems, in order to improve business processes by increasing interoperability of GAPs with new components, such as web services.
Organizations often rely on modelers to develop models of new integrated systems. Modelers may use a unified modeling language (UML) diagramming application (e.g., the ArgoUML™ application) that provides a set of graphical notation techniques to create models that describe a new integrated system. However, modelers find modeling new integrated systems that include GAPs difficult, because many GAPs are closed and monolithic and do not expose any programming interfaces or data in known formats. Although modelers desire to use GAPs as components in integrated systems, modelers find capturing the functionality and interfaces of GAPs as elements of UML-based models (e.g., classes and interfaces) difficult. Modelers find capturing properties of and dependencies between GUI objects a difficult exercise, because GUI models are often unavailable for legacy applications.
Currently, modelers use a manual, laborious, and error-prone process to study GAPs and translate GUI objects into elements of UML as abstractions of the functionalities of these GAPs. Modelers find using GAPs in modeling environments difficult, since many legacy GAPs do not expose any programming interfaces. Modelers find capturing properties of and dependencies between GUI objects a difficult exercise because GUI models are often not available for legacy applications.
Theoretically, GUI models can be extracted from the source code of GAPs, however, two fundamental limitations exist. First, the source code of GAPs often may be unavailable. For example, modeling may be outsourced to external organizations to who the source code of legacy applications may not be shared. Thus, the external organizations do not have the ability to derive precise GUI models from source code. Second, even if the external organization possesses or has access to the source code, limitations that render approaches of deriving GUI models from source code ineffective exist. For example, the Microsoft Windows™ Application Programming Interface (API) call CreateWindow, used in a large number of GAPs, takes a number of parameter variables including a string variable that holds the value of the type of a GUI object, which often may be known only at runtime.
In addition, deriving models from the source code of GAPs depends on knowing the precise semantics of API calls that create and manipulate GUI objects (e.g., CreateWindow), building appropriate parsers and analyzers for languages used to create GUI applications, and developing Integration Development Environment (IDE)-specific tools that extract GUI models from IDE GUI resource repositories. The number of tuples measures in terms of tens of thousands in the Cartesian product of API calls×programming languages×IDEs, increasing the difficulty of identifying an approach that would work with source codebases of different GUI applications.
A fundamental limitation of using GUI objects in UML models is that GUI objects are not programming objects that can be modeled using standard elements of UML. GUI objects are created within corresponding GAPs using the underlying GUI frameworks, and the GUI objects are not part of any modeling environment. Some GUI objects require users to perform multiple actions on GAPs before the GUI objects are instantiated. Without embedding these actions in UML elements, modelers find creating UML models that can be transformed into source code that uses these GUI objects difficult.
GAPs are written in many different languages and run on many different platforms. Many platform and language specific techniques for extracting data from GAPs exist. However, implementing these specific techniques in tools for different modeling platforms and languages results in multiple versions of the source code for the respective tools, increased costs to maintain the tools, and difficulties in maintaining and evolving different codebases.
Finally, modelers find generating source code from UML models that include elements describing GUI objects difficult. Classes that represent GUI objects should contain code that accesses and manipulates these GUI objects, since these GUI objects are created dynamically in the GAPs processes and the contexts of the underlying GUI frameworks (e.g., MS-Windows™ or Java™ SWT—standard widget tool kit). Since models do not reflect the contexts in which GUI objects exist, modelers find maintaining and evolving these models with respective GAPs difficult.
None of the techniques noted about are sufficiently uniform, non-invasive, and efficient. Therefore, a need exists to address the problems noted above and other problems previously experienced.